The Modules, those unknow ...

That doc will show you what are those modules, and the functions of any of them.
A Module is first of all is an Amiga standard shared library. But it is not opened by the App, only Wild (wild.library) open them when the App requests the modules to be changed. And only Wild can call them, the App NEVER calls directly them.
The particicular thing of modules is that they have all the same first 5 functions and the same type's ones have the same specific funcs (after the first 5).
The Module's generic funcs are:
- SetModuleTags(): Is used when something changes in the App's Tags, it's called by SetWildAppTags at end, after Wild has updated what is not module related (so module's opening and closing, and more). This func in the module DOES NOTHING, only REACHES THE CHANGES and STORE THEM where it want. For example, if a Display Module reaches a change in Width tag, MUST NOT RE-OPEN his screen; the only thing they can do is to adjust the changed values and change more: for example, a Display module can round the Width to 32-bit align, if needed. If you need to refresh something (like re-opening a screen) you must set the flag WAF_RefreshEngine in WildApp->wap_Flags.
- GetModuleTags(): not used not, but will ask to the module some info, for example prefs-management, or more. Now, only an empty func.
- SetUpModule(): is called at start, after the library open; must only allocate the needed app-specific structs (see WildApp->wap_EngineData field). You should also setup your values taking data from WildApp->wap_Tags; usually, this is done by calling SetModuleTags direclty from there.
- CloseModule(): is called just before closing the library, and must free everything is related to the App passed, so the ModuleData (the module's internal struct in WildApp->wap_EngineData) and more, for example the FrameBuffer, if that's a Display module.
- RefreshModule(): here's the biggest ! Is called when the WAF_RefreshEngine flag is set in WildApp->wap_Flags, and is usually called just before starting to initialize a new frame (now, InitFrame() calls that). This func must refresh everything is needed to have the module perfectly working, so to re-open the screen if dimensions changed, to remap textures if palette changed, to reinit internal 3D counts, or anything else, depending on what changed. The meaning of this apparently complex system of flags/calls is that when a module is refreshed the App's tags can change many times, for example a width can change, then be rounded, a depth can be set, then reduced, a palette can be set by the app, overwritten by a fixed-palette module (like the gouraud and flat ones), and so without the flag system the screen wuold be opened and closed a lot of times and that would be very BLEAH! Using this, the screen (and the other things, that can take some time, like remapping) are done just 1 time, when all the Tags are set to the correct values.

Now the various types of modules...

Display. That is obvious, it's the module that shows on-screen what something else draws. So, must open and mantain a screen, manage triple (or double) buffering, must update the palette, the width, the height, the depth depending on app's requests.
Specific funcs:
- DISInitFrame(): must init the frame, so fill the FrameBuffer with the correct values: for example, if you are a PLANAR display and you have 3 screens, you should select the next to be drawn and put in the FrameBuffer. Nothing more. You may reset some signals if you have to do, but that's your internal stuff...
- DISDisplayFrame(): must show the frame drawn into the buffer you set in the DISInitFrame(). So, switch the screen, or start C2P stuff, if you need. Note that CAN BE ASYNC, so if you start a C2P in background, that's good. BUT REMEMBER TO WAIT IT IN THE DISInitFrame() !! Or the chunkybuffer can be overwritten by the new rendering before be completed. ALSO, YOU HAVE TO SEND A Message WHEN FINISHED ! (FUTURE, now you can also obmit...)

TDCore. That's the main ! It's work is to prepare the 3D world to be drawn, so must convert all the Refs into the Abs, and then into the Cam, then discard out-of-view polys, backface polys, and sort them by the BSP-tree, in the ways it can (dot-based,split,or whatever...), and finally, when the array of polys is done pass it to Light module, to Broker module and finally to Draw. Does NOT call Display or PostFX, to allow you draw something on the frame if you need (the FPS, the SCORE).
IMPORTANT NOTE: Can be ASYNC, but MUST send a message when finished (FUTURE, now MUST BE SYNC).
A part must always be sync, anyway: the Rel to Abs conversion, because Abs are also used by the App and by some extensions. So, this have to be complete when returning.
Specific funcs:
- TDCRealyze(): realyzes the frame as said abuve.

Light. Simply, takes the array of polys and fills the field it has to, so the Point's light (or colorlight) or the Face one if the illumination is Flat like.
Specific funcs:
- LIGIlluminate(): does that.

Draw. Receives the array of polys, wich is now Illuminated and Broken, so just has to be drawn. Also, this module has to init the textures when they are loaded: textures are always loaded as 32bit ($AARRGGBB) and the module must convert them when needed. Note that this conversion is made by calling BuildWildObject() and making it modify the Textures, and passing the SPECIAL_TEXTURE_INIT. So, the BWO() will load the 32bit file, call DRWInitTexture() and then free the 32bit file.
- DRWPaintArray(): draws the array of polygons, sorted usually from far to near (if you don't make different requests).
- DRWInitTexture(): must allocate the needed texture memory to have the definitive image (in the format you prefer, because that is only used by you) and convert the 32bit data, so remapping if needed, or cutting bits, or more. Please, allocate the mem with AllocVecPooled (wild func, not exec !) from WildApp->wap_FastPool because FreeVecPooled is used when killing this. You must also insert the pointer in the Texture struct you have passed in.

FX. Nothing defined now, but it's the one that will draw nice lens flares and buning things and underwater FX and whatever my mind produces.

Sound. Nothing defined now. Should play samples, like explosions and more with 3D preception, but nothing now.
Maybe I'll never no, I donìt know.

Music. Nothing defined now. Should play music, but it's a big problem, because vincolate the format; but is needed to be compatible with Sound. Don't know how to solve, maybe I'll never do.

Broker. That's important: it has to Break the faces, so to do all the precalcs needed to do or speedup Drawing. So, edges steps in X,I,R,G,B,TX,TY (textureX&Y, usually called U,V). It's a separate part from Draw because many Draw may use the same Broker structs, so less code and easier to update for me.

Loader. That's called by Wild when loading from files.
These notes are directly taken from my appunti:
LOALoadObject(...): loads an object from a file, a ???, decided via tags. This object
   is keeped in memory in the Module's format.

LOAGetObjectAttr(obj,attr,default):
             asks to the loader an attribute of an object. May ask a value, like
      the object's color, or the object's position, NOT object's childs.
      Links to other friend objects are considered like attrs.
      If the attr is not supported, always return 0!
      NOTE: The loader must KNOW the type of the object passed!
      nOTE: The loader must give also the sub-attrs: explain better:
            an ARENA also have all ALIEN's attrs, and an ALIEN has also
            all the ENTITY attrs,...

LOANextObjectChild(obj,prec,childtype): asks to the loader the next child of the object. Every time, you
        pass the precedent object (or NULL at start) and that will find
        for you the next child. May even ask for a specific type of child.

LOAFreeObject(...): passes the object, and the module has to free all what it made for that,
   even tmp data or what else. A Pool use is HIGHLY recommenced: it's very
   secure, less memory frag, no forget pieces of mem...

LOAMadeObjectIs(obj,defobj): passes the made (wild format) object, and the Loader's format
     object. Needed to have a pointer to an already made alien, for
     example when you made all the aliens you can set the World's
     Player, but not before ! So, the Loader must know the location
     of the made player to say you.